Network-based game system capable of serving massive number of game players

ABSTRACT

A network-based game system includes a load balancer and one or more web servers. The load balancer can receive a plurality of requests from one or more game client applications each running on a computer device. The load balancer can store the plurality of requests in a request queue and to send one of the requests in the request queue to a web server when the web server is available to receive a new request. The one or more web servers can process one or more requests received from the load balancer. A web server can inform the load balancer that the web server is available to receive a new request when the number of requests simultaneously processed by the web server is below a predetermined number.

CROSS REFERENCES TO RELATED APPLICATIONS

This application is related to concurrently filed and commonly assignedU.S. patent application, titled “Massively scalable multi-player gamesystem” by Liu et al, the contents of which are incorporated herein byreference.

TECHNICAL FIELD

This application relates to a game system, more specifically, anetwork-based game system.

BACKGROUND

Interactive online digital entertainment has advanced on many fronts inrecent years, especially with respect to video gaming. For example,users can login to websites to find an opponent and then a game of chessor a card game in the virtual world. As a player may be competingagainst another player, the communication is bi-directional. However,not all video games can be played online. For a game of chess where timeto make a move does not have an immediate and consequential effect onthe outcome, players have time to contemplate the next move, countermove, game strategy and so on and the game does not need to providereal-time feedback. However, in a majority of real-time video games,time needed to make a decision and act upon that decision is relativelyshort so that players involved feel a sense of realism and engagement.In such a real-time game, action must occur in close proximity to reallife events. Real-time action is required for the action games,simulation games such as flight simulators and sport games. In mostcases persistent communications, scoring, player attributes, etc. cannotbe offered together with real-time realism and engagement.

Another difficulty to the network-based game systems is scalability.While some existing network-based systems can handle tens of thousandsof game players, it is a serious challenge to provide game applicationsin real time reliably and simultaneously to millions or even tens ofmillions of game players. Another challenge is to provide a large numberof game rooms each hosting a number of game players. A further desiredfeature for network-based game systems is to effectively provide a wideselection of games to the players while maintaining the same performancein real-time responses to a large number of players or offering manygames to game players within a unified social context and user identity.

SUMMARY

Implementations of the system may include one or more of the following.In one general aspect, the present invention relates to a network-basedgame system, comprising:

a load balancer configured to receive a plurality of requests from oneor more game client applications each running on a computer device,wherein the load balancer is configured to store the plurality ofrequests in a request queue and to send one of the requests in therequest queue to a web server when the web server is available toreceive a new request; and

one or more web servers each configured to process one or more requestsreceived from the load balancer, wherein each of the web servers isconfigured to inform the load balancer that the web server is availableto receive a new request when the number of requests simultaneouslyprocessed by the web server is below a predetermined number.

In another general aspect, the present invention relates to anetwork-based game system, comprising:

a load balancer configured to receive a plurality of requests from oneor more game client applications each running on a computer device,wherein the load balancer is configured to store the plurality ofrequests in a request queue and to send one of the requests in therequest queue to a web server when the web server is available toreceive a new request;

one or more web servers each configured to process a request receivedfrom the load balancer and convert the request to one or more databasequeries, wherein each of the web servers is configured to inform theload balancer that the web server is available to receive a new requestwhen the number of requests simultaneously processed by the web serveris below a predetermined number; and

a plurality of data bases storing game information that can be retrievedin response to the data queries.

In yet general another aspect, the present invention relates to a methodfor providing game services, comprising:

receiving a request from a game client application running on a remotecomputer device;

storing the request on a load balancer;

determining the number of requests simultaneously processed by a webserver;

assigning the web server the status of being available for receiving anew request if the number of requests simultaneously processed by a webserver is below a predetermined number;

sending the status of the web server from the web server to the loadbalancer;

sending the request stored on the load balancer to the web server if thestatus of the web server received by the load balancer indicates thatthe web server is available for receiving a new request; and

processing the request at the web server to produce one or more database queries in accordance to the request.

Implementations of the system may include one or more of the following.The one or more web servers can convert the requests from the gameclient applications to data base queries. The network-based game systemcan further include a plurality of data bases storing game informationthat can be retrieved in response to the data queries. The network-basedgame system can further include a connection pool server incommunication with the one or more web servers and the data bases,wherein the connection pool server is configured to direct one of thedata base queries to one of the data bases on which the game informationrelated to the data base query is stored. The connection pool server isconfigured to communicate with the one or more web servers and the databases in persistent network connections. The data bases can beconfigured to store game information including one or more of useridentification, user account information, users' gaming history, user'sgame preferences, users' credits and currencies, users' contacts,playmates, teammates, and buddies, session identification, and game roominformation. The load balancer can be configured to store statusinformation about one or more of the web servers, and wherein the statusinformation indicates whether the web servers are available orunavailable for receiving new requests. At least one of the web serverscan store a game-system-interface (GSI) program that can convert theplurality of requests from the game client applications to data basequeries. The GSI program can communicate with the game clientapplications in a non-persistent network connection.

Embodiments may include one or more of the following advantages. Anadvantage of the present invention is that the disclosed network-basedgame system can effectively provide gaming services to a massive numberof game players while maintaining performance at the gaming website. Thearchitecture of the disclosed network-based game system can be scaled tohandle the increased amount of user data, game information, andsimultaneous web requests by the game players as the number of gameplayers rapidly increases. The disclosed network-based game system canprovide excellent network performance when the user base is increasedfrom hundreds of thousands, to millions of players and beyond.

Another advantage of the present invention is that the disclosednetwork-based gaming system can provide game applications simultaneouslyto many remote game players. A plurality of game players can play thesame game in the same game room from different locations convenient tothem. Many game players can play the same game applications whilecompeting against each other or play separate game applications. Thepersistent communication paths allow game applications to be played withinstantaneous responses without network latency at multiple remotelocations.

Another advantage of the invention is that the disclosed system canprovide many game applications to remote game players over a computernetwork using different serialization encryption protocols such asATOMIC, XML, AMF, XML-RPC, etc. The game players can access gameapplications based on any of the protocols from a single network-basedservice. The selection of the game applications is significantlyincreased. Different game applications used by different game playerscan use different encryption protocols to play the same game or evenplay in the same game room.

Yet another advantage of the present invention is that the disclosedsystem can provide game applications to remote game players withpersistent network connections while efficiently tracking and updatingthe game status of each of the players in an efficient manner. Thedisclosed system includes a persistent communication path that providesinstantaneous message exchanges for the game applications in real time.The disclosed system includes a separate communication path that canrespond to the requests game applications without consuming significantnetwork resources and store game status information in storage devices.

Still another advantage of the invention is that the disclosed gamesystem is efficient. The disclosed game system includes a communicationpath to the game client that does not need to be persistent through agame session. A call from the game client is answered and thecommunication session is closed and network connection freed up.

The efficient communication architecture allows the disclosed system tobe scaled up easily without consuming significant network bandwidth asin the prior art systems. It can host millions of game players inmillions of game sessions over a computer network. The number of gameplayers supported by the disclosed system can be one or more orders ofmagnitudes higher than conventional network-based game systems.

Another advantage of the present invention is that it allows scalabilityto the hosting of a large number of game players in the same game roomor in different game rooms. The communications to the game clientapplication are divided into a persistent communication and an efficientbut non-persistent communication path. The amount of informationcommunicated in real time is minimized. A flexible layer bygame-system-interface (GSI) program handles the non-persistentcommunications, which allows the network-based game system to handle alarge number and variety of game client applications.

The details of one or more embodiments are set forth in the accompanyingdrawing and in the description below. Other features, objects, andadvantages of the invention will become apparent from the descriptionand drawings, and from the claims.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a system diagram of the network-based game system inaccordance with the present invention.

FIG. 2 shows a game client application that can be running on a computerdevice shown in FIG. 1.

FIG. 3 shows a game engine application that can be stored on a gameserver shown in FIG. 1.

FIG. 4A shows a Game System Interface application that is stored on aserver in the network-based game system shown in FIG. 1 in accordance toan embodiment of the present invention.

FIG. 4B shows a Game System Interface application that is stored on aweb server of FIG. 1 in accordance to another embodiment of the presentinvention.

FIG. 5 shows a system diagram of a persistent and efficient gamearchitecture compatible with the network-based game system of FIG. 1.

FIG. 6 shows a system diagram of a game architecture compatible with thenetwork-based game system of FIG. 1. The game architecture is capable ofcommunicating in serialized messages under a plurality of communicationprotocols.

FIG. 7 shows a table that lists a plurality of game engines that cancommunicate under different serialization protocols.

FIG. 8 shows a flow chart for the communication between the Game SystemInterface application and a game client application or a game engine ina network-based game system.

FIG. 9 is a block diagram for the client application, the load balancer,and the web servers.

FIG. 10 is a block diagram for the web servers, the connection poolers,and the data bases.

FIG. 11 is a flow chart for the communications among the web servers,the connection poolers, and the data bases.

DETAILED DESCRIPTION

Reference will now be made in detail to the preferred embodiments of theinvention, examples of which are illustrated in the accompanyingdrawings. While the invention will be described in conjunction with thepreferred embodiments, it will be understood that they are not intendedto limit the invention to these embodiments. On the contrary, theinvention is intended to cover alternatives, modifications andequivalents, which may be included within the spirit and scope of theinvention as defined by the appended claims. Furthermore, in thefollowing detailed description of the present invention, numerousspecific details are set forth in order to provide a thoroughunderstanding of the present invention. However, it will be obvious toone of ordinary skill in the art that the present invention may bepracticed without these specific details. In other instances, well knownmethods, procedures, components, and circuits have not been described indetail as not to unnecessarily obscure aspects of the present invention.

Shown in FIG. 1, a network-based game system 100 can provide gameapplications over a communication network 105 to be played on manycomputer devices 106 and 107. The communication network 105 can includevarious wired, wireless, satellite communication arrangements includingbut not limited to a wide area network such as the Internet, a localarea network, a cellular phone network under various communicationprotocols such as 2G, 2.5G and 3G, Global System for MobileCommunications (GSM), General Packet Radio Service (GPRS), EDGE, CodeDivision Multiple Access (CDMA), Wideband CDMA, TD-SCDMA, UniversalMobile Telecommunications System (UMTS), etc., and Wi-Fi wirelesscommunication standards such as IEEE 802.11, Wi-Max, and IEEE 806.16,and others. The computer devices 106 and 107 can include personalcomputers, portable digital assistance (PDA) devices, cell phones,digital image capture devices, and dedicated game devices such asMicrosoft XBOX, the SONY PlayStation OR PS2, and/or the Nintendo 64,GameCube, or GameBoy.

The network-based game system 100 can include a load balancer 115, oneor more web servers 121-124, one or more session server system 130, aserver 140, one or more game servers 141-143, one or more connectionpoolers 160, one or a plurality of databases 150, and a storage areanetwork 151 in connection with the data bases 150. The network-basedgame system 100 can be operated by a game service provider such as GaiaInteractive Inc., based in California, USA. The network-based gamesystem 100 can provide a website such as www.gaiaonline.com on theInternet to host a game community and provide various game services suchas games, discussion groups, and mails etc. A player can sign up at thewebsite to own his or her own account. The player can also personalizehis or her own profiles. As described below, the network-based system100 can store game statistics and other game properties associated witha player in a networked storage device, available and updatable to thegame player.

A game player can access the web site of the game service provider usingcomputer devices 106 and 107 with a web browser application executed onthe computer devices 106 or 107. The web browser applications areavailable from several manufacturers including Internet Explorer™ fromMicrosoft, Netscape™ from AOL, and Firebox™ from Mozilla and so on.Various Internet browsing applications are available to cellular phones,PDAs, game consoles, which are also compatible with the disclosed systemand methods.

A game client application 200 can reside on the computer device 106 or107 as shown in FIG. 2. The game client application 200 can be executedby a plug-in to the web browser application. The game client application200 can include game logic for one or more games and enable animationdisplay for the games. The web-browser plug-in can enable the webbrowser to audio or video messages and properly display vector graphicsimages independent of the manufacturer or the version of the webbrowser. The web-browser plug-in can allow animations to be properlyscaled to as web browser window is resized. The game client application200 can use the web browser's communication API (Application ProgrammingInterface) to communicate with various servers and devices (115,121-124, 140-143 etc.) in the network-based game system 100.

Specifically, without limitation, the computer devices 106 and 107 canbe installed with Flash plug-in produced by Macromedia Inc. Flash is abandwidth friendly and browser independent vector-graphic animationtechnology. Animation is choreographed using one or more sequentialtimelines in which actions and interactions are defined. The Flashplug-in is attached to the web browsers running on the computer devices106 and 107 to allow the web browser play SWF (Small Web Format) movieclips referenced in a webpage. Macromedia's Flash MX and Freehandapplications and other Flash files can also be viewed through a Webbrowser plug-in (or the Flash player) or multimedia applications thataccess the player directly. Flash files can include sound. Flash can usethe FLA files for source files and SWF files for the Flash movies. Flashfiles are space-efficient and suitable for interactions, comparing toother movie files (AVI, MPG, etc.) files.

The game client application 200 can be written in one or more SWF movieclips to be loaded in the web browser. Each game client application 200can correspond to one or more games. The SWF movie clips include gamelogic as well as animations, images, and other effects. The SWF movieclips can communicate with servers in the network-based game system 100using the library of functions provided by Macromedia's Flash plug-in. Alibrary of APIs can be developed for the SWF movie clips that can bere-used in multiple games.

FIG. 3 shows a game engine application 300 stored on a game server 141,142, or 143. The game engine application 300 is responsible forproviding real-time responses to the game client application 200 duringa game session. In the present application, the term “real-timecommunication” refers to the types of communications facilitated by apersistent network connection. The persistent network connection allowsinstantaneous and reliable communications between two components overthe network without network latency.

The game server 141, 142, or 143 on which the game engine application300 is stored can keep an open socket connection with the computerdevice 106 or 107. The game engine application 300 and the game clientapplication 200 can send and receive TCP/IP messages to and from eachother by writing and reading data to and from the socket. Messages canbe sent and received from either the game server 141 (or 142 and 143) orthe computer device 106 or 107 at any time. The persistent networkconnection allows instantaneous two-way communications and guaranteesthe games updated in real time without network latency at all timeduring a game session. A loss of connection in the persistentcommunication can be interpreted as that the game client application 200has left the game.

The game engine application 300 is compatible with different serversoftware implementations such as Sushi Multiuser Server available at“www.wok2.de”, ElectroServer 3 available at “www.electrotank.com”, andTerazona Network Engine available at “www.zona.net”. The network-basedgame system 100 can include many the game engine applications 300developed using different server software. Different server software mayrequire serialized messages encrypted under different serializationprotocols. The communication protocols with these game engineapplications 300 are provided by the GSI program 400.

The message serialization and de-serialization are used as examples ofthe encryption and decryption methods in the disclosed system andmethods. The examples are meant to depict the flexibility and capabilityof the invention system. The present invention is compatible with otherencryption and decryption techniques, and associated protocols.

The network-based game system 100 includes a Game System Interface (GSI)program 400 that can be stored on a server 140 as shown in FIG. 4A, onthe web server 121, 122, or 123 as shown in FIG. 4B, or on other serverssuch as the game servers 141-143 connected to the computer network. Thisserver that the GSI program 400 resides on can be a single computer or aload-balanced cluster of servers. Each request to the GSI program 400 isan autonomous transaction and therefore does not require a persistentconnection between the GSI program 400 and the other party (e.g. thegame client application 200 or the game engine application 300).

The GSI program 400 provides information to clients such as the gameclient application 200 in response to requests but does initiatecommunications. The GSI program 400 can respond to the requests from thegame client applications 200 running on the computer devices 106 and107. Similarly, the GSI program 400 can also provide game information inresponse to the requests from the game engine application 300.

FIG. 5 shows a system diagram of a persistent and efficient gamearchitecture 500 in the network-based game system 100. The persistentand efficient game architecture 500 include the game client application200, the game engine application 300, and the GSI program 400, whichprovide a persistent communication path and an efficient butnon-persistent communication path for the game client application 200.The GSI program 400 is connected to the database 150 and a Storage AreaNetwork 151 for saving updated data in the current game and retrievingdata from the current and past games. The games are run on the gameclient applications 200 and communicate with the game engineapplications 300 through the protocols defined by the game clientapplication 400.

One or more connection poolers can be added between the web servers121-124 or the server 140 running the GSI 400 and the data bases 150 tosupport a large number of game players. The connections between the webservers 121-124 or the server 140 and the data bases 150 are combined toform proxy database connections by the connection poolers. The proxydatabase connections can be efficiently used to process simultaneous webqueries by the game client applications 200. Details of the scaled upnetwork-based game system is shown in FIG. 10.

An advantageous feature of the disclosed network-based game system isthat it includes a persistent communication path and a non-persistentcommunication path for the remote game client application. Thepersistent communication path is used for exchanging short andinstantaneous messages that a game needs to be updated in real time, butdoes not need to be stored permanently on data storage. The real-timetwo-way communications between the game client application 200 and thegame engine application 300 are fast and without network latency. Thereis no cycle time spent on accessing and storing the exchange informationon a data storage device. The persistency of the network connectionbetween the game client application 200 and the game engine application300 typically last through a game session.

The non-persistent communication path is efficient, which allows theamount of information communicated in real time to be minimized. As aresult, the network-based system is scalable to a large number of gameplayers. The non-persistent communication path is used to communicateinformation that is of “long-term” use to the games or the game playersand does not require instantaneous and resource-intensivecommunications. The information may include the attributes andstatistics of the game player such as his or her game scores, theequipment he or she purchased to be used in the games, the “money” he orshe owns from the past and the current games, and so on. The informationnot only is needed for the current game, but also needs to be stored andretrieved for future games. Thus the information exchanged between thegame client application 200 and the GSI program 400 often involves theaccess or retrieving data from the database 150 and a data storagedevice such as SAN 151, and writing and saving data to the database 150and a data storage device. The interactions between the game clientapplication 200 and the GSI program 400 are usually single requests thatcan be answered. The connection is then closed. In other words, nopersistent network connection is required for these communicationsthroughout a game session.

The persistent and efficient game architecture 500 shown in FIG. 5differs from certain prior art systems that integrate the differenttypes of communications into the same application layer. The sameapplication layer handles real-time persistent communications andcommunications that do not need to be real time (which is in contrast tothe separate game engine application 300 and the GSI 400 provided in thepersistent and efficient game architecture 500). This type of prior artsystems requires persistent network connections for both types of servercommunications throughout the game sessions. Each of the serverinstances is to be managed by a much larger and more resource-intensiveapplication layer than the presently disclosed system. The burden to theapplication layer grows rapidly as the number of game clients or thenumber of games grows, which often increases the chance for failure,slows the responses, or degrades reliability. Furthermore, the presentdisclosed system is much more scalable compared to this type of priorart systems.

Each game engine application 300 can support one or many game clientapplications 200. The GSI program 400 can support many game clientapplications 200 and many game engine applications 300. The game logiccan be stored inside the game client application 200, for example, inthe form of compiled flash SWF files that are loaded on the web browserson the computer devices 106 and 107.

The game client application 200 can be loaded via web browser running onthe computer devices 106 and 107. The game client application 200 caninclude many game logics to allow a player to play many games.Alternatively, the game play logic can also be remotely stored on aserver (such as 121-124 or 140-143) in the network-based game system100. For example, the game logic can be included in the game engineapplication 300 or the GSI program 400 that can typically accommodatemore complex game logic than game client applications. The remotelystored game logic can be activated remotely in real-time with secureprocessing on the servers (such as 121-124 or 140-143) or downloaded tothe game players' computer devices 106 and 107 before a session starts.

To start a game, a game player can access a game service website such aswww.zaiaonline.com operated by Gaia Interactive Inc., based inCalifornia, USA. The game player can initiate a game session by clickinga game client application 200 on a web page presented by a web browserapplication running on a computer device 106 or 107. In the presentinvention, a game session refers to an active connection between theclient game application 200 and other programs such as game engineapplication 300 and GSI program 400 stored in the network-based gamesystem 100. The game client application 200 can also be in the form ofstream media (e.g. Flash SWF) so a game can keep loading as game-playstarts.

In one embodiment, a game can be started and a game session can beinitiated directly from the game client application 200 to the gameengine application 300 after authenticating with GSI 400, without theneed to access a webpage.

Many game client applications can be loaded on a computer device 106 or107. Each game client application 200 can include game logic for one ormore games. In one embodiment, the game client application 200 can be aFlash plug-in provided by Macromedia. The Flash plug-in can bedownloaded, installed, and attached to a web browser. The Flash plug-inallows the web browser to play SWF movie clips in the web-browser itfinds referenced in a webpage. Each SWF movie clip can include a uniquegame. The SWF movie clips contain the game logic as well as animations,images, and other effects. The SWF movie clip can communicate withservers in the network-based game system 100 using the library offunctions provided by Macromedia's Flash plug-in and libraries of APIsdeveloped for the network-based game system 100. Each game engineapplication 300 can support one or many game client applications 200 andthus many game logics.

During a game session, each game client application 200 can be supportedby a game engine application 300 with a persistent connection in thenetwork-based game system 100, that is, the game client application 200and the game engine application 300 can send requests to each other andreceive instantaneous responses at any time during a game session. Astop in the two-way communications between the game client application200 and the game engine application 300 is typically interpreted by thegame engine application 300 as the leaving of the game session by thegame client application 200.

The network-based game system 100 can include many game engineapplications 300 stored on the game servers 141-143. Each of the gameengine applications 300 can be based on different game platforms thatmay be developed by the game service provider such as Gaia Interactive,Inc., or sourced from a third party game developer. The game player canthus access a wide range of network-based games at many game engineapplications 300 that run on game platforms. Different game clientapplications 200 can be installed on the computer devices to runspecific games supported by the corresponding game engine applications300.

During a game session, the game client application 200 can pullinformation related to the specific game or game session from the gameengine application 300. The game engine application 300 can respond tothe requests instantaneously. The game engine application 300 can alsoupdate the game client application 200 with animations and short-termgame information that do not need to be permanently stored. Theshort-term information, for example, can include the position of asoccer-ball on a field as it is being kicked around, the path a player'savatar is moving along on the field or the current pose an avatar is in,and the instant message chat communication between players in a gameroom, including text-based chats and emoticons. A game room allows aplurality of remote game players to play the same game with each other.The game players can play team based competitive games such as soccer,ice hockey, or football, or they can play individual based games such asfishing, car race, etc.

In another embodiment, the network-based game system 100 can host manygame players playing the same game client applications in a common gamesession. The game players can, for example, compete with each other in aball game or fishing game in the game session. The game players playingcan also be depicted as playing in the same game room. In themulti-player game sessions, the game engine application 300 canbroadcast updates to many game client applications 200 running on manycomputer devices 106, 107 that are in the same game room.

The game engine application 300 can establish the players in the samegame room as peers. The game engine application 300 can conductpeer-to-peer communications in real time by broadcasting a player'sactions or events over that player's game client application to otherpeers' game client applications in the same game room. Each game clientapplication 200 in the game room can construct a message and request thegame engine application 300 to forward to the message another peer orall the peers in the same game room.

The GSI program 400 can respond to the requests from the game clientapplication 200 running on the computer devices 106 and 107. The GSIprogram 400 typically answers questions but does not initiate requestsby the game client applications 200. When a player enters the gamewebsite or when the player starts a game session, the game clientapplication 200 requests an authorization from the GSI program 400. TheGSI program 400 creates a new session ID for the user at login. The GSIprogram 400 verifies the user ID and session ID and returns validationmessage to authenticate the game session. The responses by the GSIprogram 400 in general do not need to be persistent. For example, theydo not have to communicate through SOCKET connections. This flexibilityallows a GSL program 400 to answer more calls and enables thenetwork-based game system 100 to handle a large number of game clientapplications and game players simultaneously.

The game client application 200 asks the GSI program 400 which game roomto join for a given game. The GSI program 400 checks informationreceived from the game engine applications 300 to see whether or not agame room has been created for that game. If the game room exists, thegame client application 200 enters it. If the game room does not exist,the game client application 200 requests the game engine applications300 to create one. The game engine application 300 creates the game roomand passes the information to the GSI program 400 for verification. TheGSI program 400 validates and returns a verification message including anew game room ID to the game engine application 300 that in turn returnsthe verification information to the game client application 200. Thegame client application enters the new game room. In this sequence ofthe communications, the GSI program 400 does not initiate the request.It only validates the information in requests it receives.

After the game engine applications 300 creates the game room, it writesinformation about the game room back into the GSI program 400 and waitsfor the GSI program 400 to validate that the game room is OK. Afterreceiving the validation from the GSI program 400, the game engineapplication 300 allows the game client application to enter the new gameroom.

The game client application 200 then requests the load of the game. Forexample, a SWF file is loaded by the plug-in at the request of the webbrowser. The SWF is executed by a Flash Plugin. Instructions inside theSWF tell it to connect to the GSI program 400. Instructions inside theSWF also instruct it to display the game environment and run the gameinteractions.

The GSI program 400 returns the variables necessary for loading the gameand information for saving game results to the game client application200. During the game session, the game client application 200 canrequest the saving of the game results. The GSI program 400 validatesthe data to be saved and returns whether or not the saving is succeeded.The GSI program 400 also gathers information about all the players inthe same game room and broadcast the information to the game room. Ingeneral, the GSI program 400 can respond to hundreds of different typesof calls by the game client applications 200. The GSI program 400 cantypically communicate with game client application 200 in the range of0.001-0.1 milliseconds depending on network latency and the processingtime. The priority for the performance of the GSI program 400 is that itcan respond to all the requests, but not necessarily in real time.

The GSI program 400 controls the load balance and the distribution ofplayers in the game rooms across multiple game servers 141-143 on whichthe game engine applications 300 reside. The GSI program 400 verifiesthat game rooms for a given game are not duplicated by accident. Duringthe game sessions, the game client applications 200 updates the GSIprogram 400 with game status information such as game statistics andgame configurations. Game statistics for example can include game scoresof a game player, the asset and money that a player has accumulated,number of games played etc. Game configuration can include gameequipment, game location, favorite games, etc.

Tokens and validation keys can also be passed from the game engineapplication 300 to the game client applications 200 to make suredifferent actions are occurring in the correct order and are not beingspoofed by the client game application 200. The game client application200 may be required to return the tokens and keys combined with othervariables to ensure that the game's integrity has not been compromised.

The GSI program 400 sends the game status information to database 150and storage area network to store the game status information into theuser account such that the user can keep his or her record even afterthe specific game session is ended.

An advantage of the present invention is that it allows scalability upto a large number of game players in the same game room or in differentgame rooms. The communications to the game client applications aredivided into persistent real-time communications and efficient butnon-persistent communications. The amount of information communicated inreal time is minimized. A flexible layer by game-system-interface (GSI)program handles the non-persistent communications, which allows thenetwork-based game system to handle an ever-increasing number andvariety of game client applications.

The GSI program 400 can also respond to requests from the game engineapplication 300 as shown in FIG. 5. The GSI program 400 providesinformation to the game engine application 300 as requested but the GSIprogram 400 does not initiate messages to the game engine application300. The game engine application 300 informs the GSI program 400 of allplayers and game rooms created. The game engine application 300 alsosends user ID, session ID, game room ID to the GSI program 400 forvalidation. The GSI program 400 responds to the game engine application300 to validate of the game rooms, the game sessions and the user ID.The game engine application 300 can communicate with the GSI application400 over its own local host loop-back IP address (since the GSI program400 can be installed and run on the same computer as the game engineapplication 300), eliminating network latency between the game engineapplication 300 and the GSI program 400.

FIG. 6 shows a system diagram of a game architecture capable ofcommunicating in serialized messages under a plurality of communicationprotocols. A plurality of game client applications 611-613 can berunning on a multiple of computer devices 106 and 107 to supportmultiple game players to play in the same or different game rooms. Eachcomputer devices 106 and 107 can host multiple of game clientapplications 611-613. The game client applications 611-613 cancommunicate with one or more game engine applications 621-623 incommunication paths that are persistent through game sessions. Theresponses are real time without network latency, but the informationcommunicated is specific to each game session and are not required to bestored after a game session is ended. The game engine applications621-623 can communicate in different languages defined by serializationcommunication protocols such as PHP (Hypertext Preprocessor), XML, AMF,XML-RPC (Remote Procedure Call), etc.

The game client applications 611-613 can also communicate with a GameSystem Interface (GSI) program 630 in an efficient communication path.The GSI program 630 is intended to provide a logical structure forconnecting the game client applications 611-613 to application logic onone or more servers in the network-based game system 100. The GSIprogram 630 can respond to requests from the game client applications611-613 and the game engine applications 621-623. Each request/responsecycle is a separate session that is not required to be persistentthrough the game session. Moreover, the requests to and responses by theGSI program 630 can be asynchronous communications. The GSI program 630includes two application layers: a GSI controller 640 and a GSI model650. The GSI controller 640 can access a game protocol library 660 thatcan be stored in a storage device connected in the network.

An exemplified table 700 in the game protocol library 660 is shown inFIG. 7. The table 700 lists a plurality of Game IDs such as “Fishing”,“Soccer”, “Halloween”, “Treasure Hunt”, “Survival”, etc. One or moregame IDs are supported by a game engine (GE1, GE2, GE3 . . . ). The gameengines GE1, GE2, GE3 . . . are coded to communicate under differentserialization protocols such as PHP, XML, AMF, XML-RPC, and PHP that canbe transported using a variety of Internet protocols, including HTTP,SMTP, and MIME. The communication protocols are independent from theoperating systems on the computer devices 106 and 107 or on the serversin the network based game system 100. The communication protocols can beindependent of the game logic, the game rooms, and the game engineapplications. Different game client applications 611-613 can even usemany different communication protocols to enter the same game room atthe same time. The GSI program 630 provides multiple messageserialization protocols, allowing multiple client types to communicatewith the game engine applications 621-623, the data base 670 and storagedevice 671 through the GSI model 650.

The GSI program 630 publishes a list of communication protocols toprovide a standardized method of message delivery. For instance, acommunication protocol can abstract different representations ofdifferent types of data into a serialized encapsulation, which allows acommon representation of data for different languages used on differentcomputer devices. Importantly, this enables communication with unknownclient applications residing on a computer whose programming language isunknown to the GSI program.

The communication protocols can include encryption rules and decryptionrules for serializing or de-serializing messages as shown in FIG. 7. Thegame client applications 611-613 and the game engine applications621-623 are built with libraries that handle the translations underdifferent protocols. For example, the game client applications 611-613and the game engine applications 621-623 can decode serialized packetinto its own internal language to understand data contained in aserialized encapsulation. Similarly, request messages to the GSI program630 can be encrypted using these natively stored protocols before sentto the GSI program 630. The game client applications 611-613 and thegame engine applications 621-623 use the communication protocols toinvoke requests to the GSI program 630 and interpret reply messages fromGSI program 630.

The GSI program 630 provides a single entry point for requests from allgame client applications 611-613. This architecture allows the gameclient applications 611-613 bundle multiple asynchronous requests in thesame HTTP requests (i.e. boxcar method). Furthermore, requests indifferent communications protocols can be bundled in the same HTTPmessage. The GSI program can subsequently respond to the bundled HTTPrequests in one bundled HTTP response. The boxcar method allowsefficient information transfer at low communication barrier. Incontrast, a game architecture comprising multiple entry points for thegame client applications cannot allow the bundling of different requestsif the requests are intended to be received by different entry points.

The GSI program 630 separates message serialization from applicationlogic. The message serialization and de-serialization is handled by theGSI controller 640 whereas the application logic is processed by the GSImodel 650. The GSI program 630 is built using a hybridized MVC (ModelView Controller) architecture including two application layers the GSIcontroller 640 and one or more GSI models 650. The GSI controller 640 isa single gateway responsible for controlling the requests and routingthe requests to specific GSI models 650 and then returning the responsesback to the game client application 611-613. Each GSI model contains theapplication logic for each particular method call. The GSI models 650accept parameters and return responses. The GSI models interpretde-serialize messages sent by the game client applications 613-613 orthe game engine applications 621-623 and serialize the responses fromthe model using the same protocol as the initial request. Viewsde-serialize messages sent by the client application and then serializethe response from the model using the same protocol as the initialrequest. In sum, the GSI controller 640 controls what application logicis called. The GSI models 650 house that application logic. The viewformats the information provided by the GSI model 650.

The architecture comprising the GSI program 621-623 include one or moreadvantages. The GSI program 621-623 allows a lightweight client toserver-side application logic. The GSI program 621-623 allows theconnection of two different servers that do not use the same programminglanguage such as Java, Flash ActionScript, and PHP. The serializationprotocol makes it possible to represent data-structures that aredifferent from one server to the next. For the data in a receivedmessage to be used by a server, the message must be de-serialized andtranslated into its own language so that the data can be manipulated.The serialization protocol provides a read-only representations of thedata. Once the data is de-serialized, it is manipulated by the nativelanguage methods until the data needs to be returned. It is thenre-serialized and sent off. The client applications can communicate withthe servers in the network-based system 100 in different messageserialization protocols. Furthermore, the application logic accessibleto GSI models 650 can be broken down into a series of discreet requestsfor specific information and each method invocation answers a specificquestion.

One or more connection poolers can be added between the web servers121-124 or the server 140 running the GSI program 630 and the data bases670 to support a large number of game players. The connections betweenthe web servers 121-124 or the server 140 and the data bases 670 arecombined to form proxy database connections by the connection poolers.The proxy database connections can be efficiently reused to processsimultaneous web queries by the game client applications 611-613.Details of the scaled up network-based game system is shown in FIG. 10.

FIG. 8 shows an exemplified flow chart for the communication betweenGame System Interface application and a game client application or agame engine. A game client application 200, 611-613 submits a request toa URL or other communication layer, which is received by the web server121-124. In step 810, the web server 121-124 instantiates a GSIcontroller 640 to handle the request. In step 820, the GSI controller640 evaluates the request and determines which communication protocol isto be used. The communication protocol may be indicated in a header inthe request message or stored at a storage location defined by an URL.The GSI controller 640 then instantiates a view object from the gameprotocol library 660. The view object can include decryption andencryption rules for the protocol. The GSI controller 640 asks the viewobject to de-serialize the request. The view object de-serializes therequest in step 830 and returns the request in a standardized format tothe GSI controller 640. The GSI controller 640 evaluates the request instep 850. The GSI controller 640 instantiates a GSI model 650 to handledifferent sections of the request. The GSI model 650 accepts theparameters passed in by the GSI controller 640 and returns a response instep 860. The GSI controller 640 captures the result of these operationsand passes them to the view object. The view object serializes theresponse in step 870. The GSI controller 640 returns the serializedresponse to the game client application 200, 611-613. A GSI program621-623 closes the request. The message from the game client application200, 611-613 often includes game status information that need to bestored in the player's account to allow the information to be availableafter the game session ends. The game status information can includegame scores of a game player, the asset and money that a player hasaccumulated, game equipment, and game location. A DAO (Data AccessObject) is instantiated in step 880. A database query (e.g. SQL query)is instantiated to update the database 150, 670 in step 890. The gamestatus information in the request is written in the storage device 671in step 895. The request/response communication cycles between the gameengine applications 300, 621-623 and the GSI program 400, 650 can beconducted in a similar fashion as described above.

The massive growth in the game players is serious challenge tocapability of a network-based gaming system. For a network-based systemsuch as www.gaiaonline.com, the number of game players can grow fromhundreds of thousands, to millions, or even tens of millions at eachtime. The massive amount of activities can produce tremendous webtraffic to the web servers in the network-based gaming system. Thespiking of web traffic by simultaneous users during the peak hours cancause an overload of the network-based gaming system, which can causesluggish web page loads, errors in connecting to data stores, and thedenial of services to the users.

In a conventional load balancing architecture, the load balancer funnelstraffic to the web servers as long as they are responding, regardless ofwhether or not the web servers can efficiently process the requests. Theload balancer guesses whether or not a web server is healthy, which canresult in a huge spurt of traffic to the web server until the web serverbecomes so overloaded and stops responding. When this situation occurs,the web server slows down; and the connection to a database stays openand sits idle longer. The productivities of the web servers and thedatabases can all take big hits. Meanwhile, the users waiting for theresponse from the web servers usually try reloading the same web pageswhen they don't get an immediate response, causing repeated requests ofthe same information to be made. During these events, the web trafficcan be so overwhelming that gaming web site becomes unusable.

The network-based game system 100 can overcome the above describedproblems by improved network architecture for the game clientapplications, the web servers, and the databases. One or a cluster ofload balancers can be placed between the web servers and the game clientapplications to manage the request to the web servers. Simultaneousrequests to individual web servers can be regulated to prevent the webservers from being overwhelmed. The connections between the web serversand the data bases are combined to form proxy database connections by aserver (i.e. connection pooler). As described below in more detailbelow, the proxy database connections with the connection poolers can beshared by web queries from different game client applications or gameengine applications. The web queries can be efficiently processed.

FIG. 9 is a block diagram for a client application 910, a load balancer920, and web servers 91-934 in the network-based game system 100. Thegame client application 910 running on a computer device 106 or 107first makes a web request 911. The web request 911 is typically made ata website hosted by the network-based game system 100 such aswww.gaiaonline.com. The request is accepted by a load-balancer server920. In general, the requests from the game client applications 910 canbe handled by one or a cluster of load-balancer servers 920 inside thenetwork-based game system 100. The requests from a number of game clientapplications 910 running on one or a large number of computer devices106 or 107 can be managed in the request queue 921 that is stored on theload balancer 920. The request queue 921 can be processed in afirst-in-first-out fashion (FIFO), that is, the oldest request in therequest queue is the always the next request to be processed.

The network-based game system 100 includes a plurality of web servers931-934. A software agent is stored in each of the web servers 931-934to keep track of the total requests handled by the web server 931-934.The agent can be programmed by a set of predetermined policies to governthe request workload at the web server 931-934. For example, the agentcan set a maximum number of requests that can be handled by each webserver 931-934. When the requests being handled by a web server 931-934is at its maximum, the software agent will flag the web server 931-934unavailable for receiving more requests. When the requests being handledby a web server 931-934 is below its maximum, the software agent canflag the web server 931-934 to be available for receiving more requests.In general, the available and the unavailable criteria can be based ondifferent request numbers with the available request number being lowerthan or equal to the unavailable request number. The constraint on themaximum request at a web server reduces the probability that the webserver becomes overloaded. The web server can therefore process webrequests quickly and move on to the next incoming web request faster.

The web server status 922 of the web servers 931-933 can be communicatedto the load balancer 920 and stored as web server status 923 in the loadbalancer 920. Once the web server status 923 indicates that one of webserver 931-934 becomes available to accept new requests, the loadbalancer 920 can send a new request 924 to that web server. The webserver communicates with the connection poolers 160, 1011-1014 to queryand retrieve the information requested (see FIGS. 10 and 11 and relateddiscussions below). The web server 931-934 returns the requestedinformation to the load-balancer cluster 920. The web server 931-934 isnow ready to accept for a new request. Meanwhile, the load-balancer 920returns requested information 912 to game client application 910. Therequested information 912 can be displayed on an html page generated bythe web server 931-934 and passed to game client application 910 throughthe load balancer 920.

As discussed above, the request queue 921, the web server status 923,and the associated communications 922, 924 with the web servers 931-934are implemented in a “pull-type” architecture that allows web requests911 to be regulated by the actual workloads of the web servers 931-934.The software agent in the web servers 931-934 allows the web requests924 to each web server 931-934 to be controlled below a maximum number.

An advantage of the “pull-type” architecture in the invention system isthe prevention of the overloading at the web servers. In contrast, a“push-type” architecture distribute requests to web servers without theknowledge of the true workload at the web servers, which can overwhelmthe web servers and degrade performance of the web servers. In somecases, an overwhelmed web server can be completely stalled. Noinformation can be returned to the load balancer or the game clientapplication.

An advantage of the invention system is that web servers can focus onprocessing the web requests by being alleviated from other tasks. Theload-balancer is responsible for receiving the entire request contentand passing requested information back to the game client application.The web servers are also relieved of the responsibility of communicatingdirectly with the game client applications. Thus the web servers willnot be dragged down if the game client applications lag. The web serversare allowed to focus on processing the requests.

The network architecture shown in FIG. 9 allows more web requests to besimultaneously processed by the network-based game system 100.Drastically improved performance was observed in the systemimplementation. For example, web page loads that took between 3-5seconds were reduced to less than 0.1 seconds. Game players experiencedfar less latency in web requests even in high-load situations. Moreover,in the rare events that the web traffic begins to top out the maximumcapacity, the performance of the network-based game system degradedgracefully and gradually, the network-based game system was not disabledor caused page load errors and other unpredictable behavior.

FIG. 10 is a block diagram for the web servers 1001-1005, a proxy servercluster 1010, and the data bases 1021-1025, which can be a portion ofthe network-based game system 100 as shown in FIG. 1. A Game SystemInterface can be run on the web servers 1001-1005 to handle the requestsfrom the game client applications 910 through the load balancer 115,920. The proxy server cluster 1010 includes a plurality of connectionpoolers 1011-1014. To conduct a data base query, a web server 1001-1005sends the query to the proxy server cluster 1010 in a persistent networkconnection. The persistent network connection between a web server andthe proxy pooler cluster 1010 is usually short-lived which lasts thelifetime of a web request. Thus many queries can be made to differentdata stores in that web request. These persistent network connectionsare stateful. (In contrast, as discussed above, the connections betweenthe game client application and GSI can be stateless and notpersistent.) In other words, a web server can authenticate a connectionpooler and then issue a series of web queries to the connection poolerover the same persistent network connection until it receives all therequested information in the web request. It then closes the persistentnetwork connection. The web server can thus use a single persistentnetwork connection with the connection poolers 1011-1014 to query manydifferent data bases 1021-1025.

In general, the requests from the game engine applications to the GSIrunning on the web servers can also be routed to the connection poolersjust like the requests from the game client applications.

The connection pooler 1011-1014 can open up persistent networkconnections with the data bases 1021-1025 to transmit the queries to theproper data base 1021-1025. These persistent network connections can belong-lived (e.g. days or even weeks). The persistent network connectionsbetween the connection pooler 1011-1014 and the data bases 1021-1025allow instantaneous two-way communications and guarantees the queriesare to be conducted without network latency. As described in detailbelow, each persistent connection can handle a large number of unrelatedqueries.

Each data base 1021-1025 can be connected with one or more computerstorage device where the game information is stored. The architectureshown in FIGS. 1 and 10 is a significant improvement from an earlierversion of the network architecture for the game system. The earlierversion of the network-based game system included one primary monolithicdatabase and a few secondary database servers. All user data werereplicated to all the other servers. As the amount of data increasedwith the number of game players and the number of games provided, thevolume of updates to the data rapidly increased. Replications began toslow down and fail. In addition, the primary database became overloadedand was unable to respond to web requests from the game clientapplications. The large amount of data stored on each machine preventedthem from being cached in dynamic memories, which meant that most of thequeries required significant disk-seek times and thus showed lowperformances.

In the invention system shown in FIGS. 1 and 10, all the data issegmented into distinct data bases 150, 1021-1025 and their associatedcomputer storages and storage area network 151. Instead of one masterdatabase, the data bases 150, 1021-1025 are all master databases that donot need to be replicated. For example, there can be 20, 30 or more databases 150, 1021-1025 in a network-based game system 100. Each data base150, 1021-1025 contains a small segment of the total data. Because thedata size stored on each data base 150, 1021-1025 is smaller and limitedto a particular service, the data base can respond much more quickly toqueries because the ‘web pages’ can be stored in dynamic memories andrequire no disk seek time. In general, the web servers 1001-1005 canalso include the sever 140 in FIG. 1 because the Game System Interface400 can also be stored on the server 140.

The data contained in the data bases 150, 1021-1025 can include gameinformation. In the present application, game information can includeinformation about the game players such as user identification, useraccount information, the user's gaming history and game preferences, theuser's credits and currencies, and the contacts, playmates, teammates,and buddies of that users. The game information can also include gamesession identification and game room information.

Another significant feature of the invention system in FIGS. 1 and 10 isthat it can efficiently handle data queries to multiple data bases foreach web request. The user data from different users or even the sameuser can be distributed on different data bases 1021-1025, the renderingof each web page by a web server can often require the opening multipleconnections to different data bases 1021-1025. A complex web page mayrequire as high as 10 such data base connections. As it is known,opening database connections involves the overhead of a socketconnection, the overhead of a thread creation in a relational databasemanagement system (RDBMS) such as mysql, and the proper management ofthe connections. As more and more web servers are added and higher andhigher numbers of connections are opened and closed, the RDBMS threadsand the web servers begin to show losses of performance.

One attempt to overcome the above described problem is to use persistentconnections between the web servers and the data bases. The large numberof web servers makes persistent connections impractical because theopenings and closings of the large number of connections still consumetoo much CPU cycles and memory at the web servers and the data bases.

It was discovered that the mysql threads could easily keep pace with thevolume of queries if there were a way to lower the overhead of the manysimultaneous web server clients. It was conceived that performance couldbe improved if one connection can be opened to a web server and can thentransparently pass off many requests to many different data bases.Finally, a proxy server cluster 1010 comprising connection poolers1011-1014 is implemented as shown in FIGS. 1 and 10 to successfullysolve the above described problem. The connection poolers 1011-1014aggregate the database connections behind a single proxy server cluster1010. The proxy server cluster 1010 acts as a middle-man between thedifferent data bases 1021-1025 and the web servers 1001-1005. Thecluster of connection poolers 1011-1014 accepts connections from the webservers 1001-1005 and passes the queries to a data bases 1021-1025transparently. The queries to the data bases 1021-1025 can re-use anexisting persistent connection to the databases 1021-1025.

The network connections between web servers 1001-1005 and the connectionpoolers 1011-104 and between the connection poolers 1011-104 and thedata bases 1021-125 and are persistent and. In other words, they areboth socket connections and they both only authenticate once and thenproceed to conduct a series of queries to another server. A web server1001-1005 can open up a connection to a connection pooler 1011-1014 forthe purpose of building one web page or to handle a GSI request. The webserver 1001-1005 makes a series of queries to the connection pooler andthen closes the connection as soon as it receives all the informationfor the GSI call. The network connection between a connection pooler anda database can stay open for days, weeks, months and until the databasefails.

An advantage of the invention system is that the web server communicateswith only one proxy server cluster 1010 throughout the generation of aweb-page or other such request. The majority of the queries passingthrough the proxy server cluster 1010 require only the opening of onedirect connection to the data bases 1021-1025.

Another advantage of the invention system is that it is reboust tohardware failures. Since the connection poolers are arranged in a proxyserver cluster 1010, the crash of any one connection pooler 1011-1014can be easily replaced by another connection pooler 1011-1014; the proxyserver cluster 1010 will not fail.

Furthermore, the proxy server cluster 1010 can be scaled up horizontallyby increasing the number of connection poolers to handle increasedworkload between the web servers and the data bases such that the CPUcycles and memory for each connection pooler is not over loaded.

The proxy server cluster 1010 in the invention system shown in FIGS. 1and 10 can be implemented as a software solution that is different fromother connection pooling approaches. In the other approaches, a databaseconnection is allocated and reserved for a web server only until the webserver releases the connection and passes the connection back into thepool. The proxy server cluster 1010 in the invention system takesadvantage of the fact that many of the web queries in the game networksystem 100 do not need to be stateful, that is, the web queries do nothave happen in a specific order and each web query can treatedseparately from the other queries. The connections can be immediatelyrecycled for a different query after each query is finished, whichextracts more query usage out of the data-base connections. A databaseconnection does not stay idle. Instead, the database connection ispassed with a constant stream of unrelated queries from many differentweb servers 1001-1005. This added middle layer of the proxy servercluster 1010 surprisingly improves the system performance. The databases 1021-1025 can now process queries faster without having to managethe web server connections. The web servers 1001-1005 can be moreefficient because they can access a huge number of data bases 1021-1025through a single connection.

FIG. 11 is a flow chart for the communications among the web servers1001-1005, the connection poolers 1011-1014, and the data bases1021-1025. Game system interface on a web server calls a data accessobject in the web server to perform data request in step 1110. The dataaccess object next formats the request as one or more queries in step1120. The data access object then passes each query to the databaseabstraction layer on the web server in step 1130. The databaseabstraction layer object on the web server contacts the proxy servercluster 1010 comprising the connection pooler 1011-1014 through a socketconnection in step 1140. The database abstraction layer object on theweb server passes the query to the connection pooler 1011-1014 in thestep 1050. The connection pooler contacts the correct data base,receives the query results from the data base, and returns the queryresult to the web server in step 160. The query result is typically inserialized message. The query result is next processed by the databaseabstraction layer in step 1170, which is in turn passed to the dataaccess object in step 1180. The query results are then returned,typically in aggregates, to the game system interface by the data accessobject in step 1190.

Although specific embodiments of the present invention have beenillustrated in the accompanying drawings and described in the foregoingdetailed description, it will be understood that the invention is notlimited to the particular embodiments described herein, but is capableof numerous rearrangements, modifications, and substitutions withoutdeparting from the scope of the invention. The following claims areintended to encompass many such modifications.

1. A network-based game system, comprising: a load balancer configuredto receive a plurality of requests from one or more game clientapplications each running on a computer device, wherein the loadbalancer is configured to store the plurality of requests in a requestqueue and to send one of the requests in the request queue to a webserver when the web server is available to receive a new request; andone or more web servers each configured to process one or more requestsreceived from the load balancer, wherein each of the web servers isconfigured to inform the load balancer that the web server is availableto receive a new request when the number of requests simultaneouslyprocessed by the web server is below a predetermined number.
 2. Thenetwork-based game system of claim 1, wherein the one or more webservers are configured to convert the requests from the game clientapplications to data base queries.
 3. The network-based game system ofclaim 2, further comprising a plurality of data bases storing gameinformation that can be retrieved in response to the data queries. 4.The network-based game system of claim 3, further comprising aconnection pool server in communication with the one or more web serversand the data bases, wherein the connection pool server is configured todirect one of the data base queries to one of the data bases on whichthe game information related to the data base query is stored.
 5. Thenetwork-based game system of claim 4, wherein the connection pool serveris configured to communicate with the one or more web servers and thedata bases in persistent network connections.
 6. The network-based gamesystem of claim 1, wherein the data bases are configured to store gameinformation including one or more of user identification, user accountinformation, users' gaming history, user's game preferences, users'credits and currencies, users' contacts, playmates, teammates, andbuddies, session identification, and game room information.
 7. Thenetwork-based game system of claim 1, wherein the load balancer isconfigured to store status information about one or more of the webservers, and wherein the status information indicates whether the webservers are available or unavailable for receiving new requests.
 8. Thenetwork-based game system of claim 1, wherein at least one of the webservers is configured to store a game-system-interface (GSI) programthat can convert the plurality of requests from the game clientapplications to data base queries.
 9. The network-based game system ofclaim 8, wherein the GSI program is configured to communicate with thegame client applications in a non-persistent network connection.
 10. Anetwork-based game system, comprising: a load balancer configured toreceive a plurality of requests from one or more game clientapplications each running on a computer device, wherein the loadbalancer is configured to store the plurality of requests in a requestqueue and to send one of the requests in the request queue to a webserver when the web server is available to receive a new request; one ormore web servers each configured to process a request received from theload balancer and convert the request to one or more database queries,wherein each of the web servers is configured to inform the loadbalancer that the web server is available to receive a new request whenthe number of requests simultaneously processed by the web server isbelow a predetermined number; and a plurality of data bases storing gameinformation that can be retrieved in response to the data queries. 11.The network-based game system of claim 10, further comprising aconnection pool server in communication with the one or more web serversand the plurality of data bases, wherein the connection pool server isconfigured to direct a data base query to one of the data bases on whichthe game information related to the data base query is stored.
 12. Thenetwork-based game system of claim 11, wherein the connection poolserver is configured to communicate with the one or more web servers andthe data bases in persistent network connections.
 13. The network-basedgame system of claim 10, wherein the data bases are configured to storegame information including one or more of user identification, useraccount information, users' gaming history, user's game preferences,users' credits and currencies, users' contacts, playmates, teammates,and buddies, session identification, and game room information.
 14. Thenetwork-based game system of claim 10, wherein the load balancer isconfigured to store status information about the one or more webservers, and wherein the status information indicates whether the webservers are available or unavailable for receiving new requests.
 15. Thenetwork-based game system of claim 10, wherein at least one of the webservers is configured to store a game-system-interface (GSI) programthat can convert the plurality of requests from the game clientapplications to data base queries.
 16. The network-based game system ofclaim 15, wherein the GSI program is configured to communicate with thegame client applications in a non-persistent network connection.
 17. Amethod for providing game services, comprising: receiving a request froma game client application running on a remote computer device; storingthe request on a load balancer; determining the number of requestssimultaneously processed by a web server; assigning the web server thestatus of being available for receiving a new request if the number ofrequests simultaneously processed by a web server is below apredetermined number; sending the status of the web server from the webserver to the load balancer; sending the request stored on the loadbalancer to the web server if the status of the web server received bythe load balancer indicates that the web server is available forreceiving a new request; and processing the request at the web server toproduce one or more data base queries in accordance to the request. 18.The method of claim 17, further comprising: sending the data basequeries to one or more data base wherein game information is stored;querying the one or more data bases to retrieve the game informationrequested by the data queries; and sending the retrieved gameinformation to the game client application.
 19. The method of claim 17,further comprising: receiving a plurality of requests from one or moregame client applications running on remote computer devices; storing therequests in a request queue on a load balancer; and sending one of therequests in the request queue if the status of a web server received bythe load balancer indicates that the web server is available forreceiving a new request.
 20. The method of claim 19, further comprising:sending the oldest request in the request queue to the web server.